Make retags an implicit part of typed copies by RalfJung · Pull Request #154341 · rust-lang/rust

RalfJung · 2026-03-24T22:06:19Z

Ever since Stacked Borrows was first implemented in Miri, that was done with Retag statements: given a place (usually a local variable), those statements find all references stored inside the place and refresh their tags to ensure the aliasing requirements are upheld. However, this is a somewhat unsatisfying approach for multiple reasons:

It leaves open the question of where to even put Retag statements. Over time, the AddRetag pass settled on one possible answer to this, but it wasn't very canonical.
For assignments of the form *ptr = expr, if the assignment involves copying a reference, we probably want to do a retag -- but if we do a Retag(*ptr) as the next instruction, it can be non-trivial to argue that this even retags the right value, so we refrained from doing retags in that case. This has come up as a potential issue for Rust making better use of LLVM "captures" annotations. (That said, there might be other ways to obtain this desired optimization.)
Normal compilation avoids generating retags, but we still generate LLVM IR with noalias. What does that even mean? How do MIR optimization passes interact with retags? These are questions we have to figure out to make better use of aliasing information, but currently we can't even really ask such questions.

I think we should resolve all that by making retags part of what happens during a typed copy (a concept and interpreter infrastructure that did not exist yet when retags were initially introduced). Under this proposal, when executing a MIR assignment statement, what conceptually happens is as follows:

We evaluate the LHS to a place.
We evaluate the RHS to a value. This does a typed load from memory if needed, raising UB if memory does not contain a valid representation of the assignment's type.
We walk that value, identify all references inside of it, and retag them. If this happens as part of passing a function argument, this is a protecting retag.
We store (a representation of) the value into the place.

However, this semantics doesn't fully work: there's a mandatory MIR pass that turns expressions like &mut ***ptr into intermediate deref's. Those must not do any retags. So far this happened because the AddRetag pass did not add retags for assignments to deref temporaries, but that information is not recorded in cross-crate MIR. Therefore I instead added a field to Rvalue::Use to indicate whether this value should be retagged or not. A non-retagging copy seems like a sufficiently canonical primitive that we should be able to express it. Dealing with the fallout from that is a large chunk of the overall diff. (I also considered adding this field to StatementKind::Assign instead, but decided against that as we only actually need it for Rvalue::Use. I am not sure if this was the right call...)

This neatly answers the question of when retags should occur, and handles cases like *ptr = expr. It avoids traversing values twice in Miri. It makes codegen's use of noalias sound wrt the actual MIR that it is working on. It also gives us a target semantics to evaluate MIR opts against. However, I did not carefully check all MIR opts -- in particular, GVN needs a thorough look under the new semantics; it currently can turn alias-correct code into alias-incorrect code. (But this PR doesn't make things any worse for normal compilation where the retag indicator is anyway ignored.)

Another side-effect of this PR is that -Zmiri-disable-validation now also disables alias checking. It'd be nicer to keep them orthogonal but I find this an acceptable price to pay.

RalfJung · 2026-03-24T22:46:18Z

@bors try
@rust-timer queue

Make retags an implicit part of typed copies

rust-bors · 2026-03-25T00:55:08Z

☀️ Try build successful (CI)
Build commit: 82d9903 (82d99031f4626ac962af0c7f6d78d1f7173d7145, parent: 362211dc29abc4e8f8cfc384740237f144929b03)

RalfJung · 2026-03-25T06:57:45Z

Looks like enabling validation of references just to keep retags working in const-eval was not a good idea...

RalfJung · 2026-03-25T07:24:27Z

@bors try
@rust-timer queue

Make retags an implicit part of typed copies

rust-bors · 2026-03-25T09:32:55Z

☀️ Try build successful (CI)
Build commit: 5bbea76 (5bbea7620d94ef1e4dd2e6617ed840cde1cf87f3, parent: 8a703520e80d87d4423c01f9d4fbc9e5f6533a02)

fee1-dead · 2026-03-29T05:06:58Z

please let me know if you're comfortable reviewing this (in due time of course, no rush), or if I should go look for someone else.

Sorry for the late reply, I took a shallow look today and I don't think I'd be able to review the changes (specifically MIR transforms semantics). So I'll reroll, feel free to r? someone, of course.

@rustbot reroll

oli-obk · 2026-04-12T12:11:30Z

there's a mandatory MIR pass that turns expressions like &mut ***ptr into intermediate deref's. Those must not do any retags. So far this happened because the AddRetag pass did not add retags for assignments to deref temporaries, but that information is not recorded in cross-crate MIR. Therefore I instead added a field to Rvalue::Use to indicate whether this value should be retagged or not.

Before I dive into this PR, does that mean that only Use rvalues in those split derefs ever use a different value for the new field at this stage? Everthing else has Use rvalues which do retagging?

Because I'm getting the feeling you've discovered a representation that may allow us to move the derefer pass before borrowck, because borrowck now has a trivial way to figure out whether it should... "retag"

RalfJung · 2026-04-12T12:26:56Z

Before I dive into this PR, does that mean that only Use rvalues in those split derefs ever use a different value for the new field at this stage? Everthing else has Use rvalues which do retagging?

Correct. MIR building always sets WithRetag::Yes. The erase-deref-temp and deref-separator passes and some MIR opts (InstSimplify, LargeEnums, MatchBranches) are the only places that introduce no-retag uses.

Because I'm getting the feeling you've discovered a representation that may allow us to move the derefer pass before borrowck, because borrowck now has a trivial way to figure out whether it should... "retag"

Maybe? I don't know enough avout borrowck to judge this. :)

Note that the derefer pass introduces CopyForDeref, so the representation of what that pass does is not touched by this PR. This PR only changes what happens with CopyForDeref later in the MIR pipeline. It seems possible that CopyForDeref can be entirely replaced by no-retag uses, but that touches too much code I am not familiar with.

rustbot · 2026-04-23T15:12:11Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

oli-obk

r=me with an explanation of the mutable reference instead of raw pointer (the comment talks about a raw pointer, but the code uses a mutable reference coerced to a raw pointer now)

View changes since this review

oli-obk · 2026-04-27T08:45:11Z

I'll investigate this after this PR lands, there are some easy cases, and some annoying ones, so I'll start by keeping around whether the copied operands had retags or not

oli-obk · 2026-04-28T10:10:55Z

+        // operation for it's alias tracking. It would be wrong for `into_raw_with_allocator` to
+        // do the same as that would induce uniqueness assumptions that we only want with
+        // the default allocator.
+        &mut **b


this now also goes through an intermediate mutable reference, why is that?

It is so that in MIR there ends up being a reference-to-raw-ptr-cast, and that is what Stacked Borrows recognizes. I'll extend the comment.

dianqk · 2026-04-28T10:51:37Z

I have a small concern. After the patch, must we be careful about whether to retag or not when creating a new copy? Can we always create a non-retag for transformation? IIUC, the answer is no. This will make Miri much less useful. This can make a transformation pass more confusing.

In LLVM, we can just drop UB via dropUBImplyingAttrsAndMetadata.

RalfJung · 2026-04-28T11:40:04Z

It's always safe to turn a retagging copy into a non-retag one. So dropUBImplyingAttrsAndMetadata would choose WithRetag::No. (But note that most rvalues don't have a way of opting-out from the retag at the moment.)

This will make Miri much less useful.

I think the opposite is true. Currently the optimizations and Miri live in a different world, making it impossible to actually reason about what optimizations do in a way that is coherent with Miri. We'll need to either turn on retags by default or make them implicit in MIR to move mir-opts and Miri into the same world; only then can Miri be useful to check concrete optimization examples.

…tead

RalfJung · 2026-04-28T13:45:31Z

@bors try jobs=x86_64-gnu-aux

Make retags an implicit part of typed copies try-job: x86_64-gnu-aux

rust-bors · 2026-04-28T15:57:21Z

☀️ Try build successful (CI)
Build commit: 2592ffc (2592ffc844ff395407ce625242df6399451d7890, parent: 4ddb0b7f8ecda9dbdbcbc0519c9988badbd65d1c)